Skip to content

Issue #123 - Removing Macros#369

Open
Rederick5 wants to merge 295 commits intoMSRevive:devfrom
Rederick5:dev
Open

Issue #123 - Removing Macros#369
Rederick5 wants to merge 295 commits intoMSRevive:devfrom
Rederick5:dev

Conversation

@Rederick5
Copy link
Copy Markdown
Contributor

@Rederick5 Rederick5 commented Mar 24, 2026

This is partial completion. Changed a bit more than I probably should have, but standards indicate that changing to typesafe non-macros should be a good end goal, should it be able to be done safely.

For now, left a lot of the more complex macros, such as the loggers/message and engine callbacks alone.
Changed as many macro functions to class member/file functions / unrolled macros where possible.

Left thirdparty/public/engine files alone for the most part.

Changed all the vec3_t to Vector class, removed all #define constants I could with constexpr/enum where possible.
Resolved a few header inclusion issues / duplicated defines.

changed vector class to be able to be initialized as constexpr class objects.

I can compile without issue and some light testing indicates general stability, but comprehensive testing needs to be completed.

Script events in edana have tested successfully, etc.

FALSE is still cast as int
TRUE is still defined as int
NULL is still defines as int

future issue recommended to change these to true/false/nullptr/0 where applicable

Rederick5 added 30 commits March 8, 2026 18:01
Addeec constexpr to defined constants.
FIxed warning C5055 after enum changes.
Fixed wasrning on unintialized variables.
Templated clrmem() macro
moved include to top of file.
Removed duplicate enum def.
Changes macros to constexpr/enums in util.h
Fixed / changed unneeded assignment.
@Rederick5
Copy link
Copy Markdown
Contributor Author

#define GRAPH_VERSION (int)16 // !!!increment this whever graph/node/link classes change, to obsolesce older disk files.
Line: 149 - nodes.h
Is this increment needed or is this basically just an early version of version control?

@SaintWish
Copy link
Copy Markdown
Member

#define GRAPH_VERSION (int)16 // !!!increment this whever graph/node/link classes change, to obsolesce older disk files. Line: 149 - nodes.h Is this increment needed or is this basically just an early version of version control?

I would just keep that macro since it's part of the SDK

@Rederick5
Copy link
Copy Markdown
Contributor Author

Rederick5 commented Mar 24, 2026

#define GRAPH_VERSION (int)16 // !!!increment this whever graph/node/link classes change, to obsolesce older disk files. Line: 149 - nodes.h Is this increment needed or is this basically just an early version of version control?

I would just keep that macro since it's part of the SDK

More wondering if we should increment the value to 17 but since it's sdk guess it doesn't really matter.

Copy link
Copy Markdown
Member

@SaintWish SaintWish left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Can you revert the macro changes in the src/public and src/engine files because we should avoid making macro changes to the engine SDK header files.

We should avoid making changes to the thirdparty/angelscript, since it's a thirdparty library source we should avoid making changes to it.

@tschumann
Copy link
Copy Markdown
Contributor

tschumann commented Mar 26, 2026 via email

@Rederick5
Copy link
Copy Markdown
Contributor Author

If the files need to be 1:1 the same I can remove the using vec3_t added and move back to a define in the vector.h header.
There's some comparisons between objects in the sdk which flag signed/unsigned mismatch warning. 6 ints changed in the last commit. if I know which side of the comparison can safely be casted, I can keep these as vanilla and just static cast in the comparisons that they are referenced. It's about 90 some warnings but would prefer not to pragma disable it.

@tschumann
Copy link
Copy Markdown
Contributor

tschumann commented Mar 26, 2026 via email

@Rederick5
Copy link
Copy Markdown
Contributor Author

Looks like changing 3 of the sdk files to vec3_t will cause some problems with this PR that will take time to resolve.
When the headers reference the type directly or via a using statement there is no issue finding the type, but switching back to the define or a typedef in vector.h is resulting in some unknown identifier and type specifiers.

Might just be a few cpp files missing the appropriate includes, but not sure why it would work as a straight specification but fail when using a macro define unless it's just how the linker is processing. I'm pretty green when it comes to working with any linker issues.

the using vec3_t = Vector at the top of:

eiface.h
progdefs.h
studio.h

or leaving the vec3_t as Vector allows for compile.

If absolutely needed to leave these as vanilla I'll probably need to wade back into the files and ensure vector is being included appropriately. I know I changed a few of the includes when removing defines caused redefinition problems.

@SaintWish
Copy link
Copy Markdown
Member

You can just leave the Vector then if it'll compile.

@Rederick5
Copy link
Copy Markdown
Contributor Author

Rederick5 commented Mar 26, 2026

Was able to find the include issue in animation.cpp. the public files should now all be base and the signed/unsigned mismatch warnings resolved.

Also reverted changes to the two third party files.

Copy link
Copy Markdown
Member

@SaintWish SaintWish left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Can you also revert the macro changes in src/common since those are also engine header files?

Missing M_PI def for a few files.
Re-added nanmask int.
Added hard define for missing enums, 'unable to open header file' and it's commented out of another common file.
@Rederick5
Copy link
Copy Markdown
Contributor Author

Rederick5 commented Mar 26, 2026

That one hurts a bit, quite a few hours worth, but it has been done, with a few quick fixes to fill in missing defines.
Did you also want the utils\common reverted?

@SaintWish
Copy link
Copy Markdown
Member

That one hurts a bit, quite a few hours worth, but it has been done, with a few quick fixes to fill in missing defines. Did you also want the utils\common reverted?

Nope, I think everything else is good.

@SaintWish
Copy link
Copy Markdown
Member

Since everything looks good and compiles, I'll probably accept it next week sometime.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants